Week 11 of 12 · The Lead

A Safety Taxonomy

Before you can label harm, you have to define it — clearly, exhaustively, and without overlap. That document is the spine of all safety data.

Day 51 ~75 minutes Concept

Day 51 of 66

Why safety data starts with a definition, not a label

For ten weeks you've been making models better. This week you make them safer — and the work is the same discipline turned to higher stakes. Safety data is just human data where a wrong label can cause real harm: a model that helps with something it shouldn't, or one that refuses an ordinary, benign request. Both are failures. Both are expensive. And both start with the same question: what exactly counts as harmful here?

This is defensive work. You are not learning to attack models or extract dangerous content. You are learning to build the data that teaches a model where the lines are — so it can stay on the right side of them. The first artifact in that effort is a safety taxonomy.

What a safety taxonomy is

A safety taxonomy is a set of clear, mutually-exclusive harm categories, each with a definition and severity tiers. It's the rubric of Week 2 pointed at harm: it tells every annotator on the team what "violence" means versus "self-harm," what counts as a violation versus a gray area, and how serious each one is. Without it, ten annotators produce ten different notions of "unsafe" — and the model learns noise.

The two properties that make a taxonomy usable

A taxonomy that looks reasonable in a doc can still produce inconsistent labels. Two properties prevent that.

Core Theory

1 · Categories must be mutually exclusive

If an item can plausibly land in two categories, two annotators will split — and your agreement (Week 3) collapses for reasons that have nothing to do with skill. Overlap is the single most common defect in a safety taxonomy. When "harassment" and "hate" both seem to fit, that's not a hard case; that's a boundary you forgot to draw. Every overlap you leave in the doc becomes a disagreement you'll pay for at scale.

2 · Categories must be collectively exhaustive — with a clean exit

The real world will hand your team things the taxonomy didn't anticipate. So the set needs a deliberate none / benign bucket and an other — escalate bucket. The first says "this is fine, no harm here." The second says "this is harmful but doesn't fit — a human decides, and the taxonomy gets updated." Never force a real item into a wrong category just because the list felt complete.

Notice the through-line from Week 2: a safety category definition needs the same things a quality dimension needed — a one-line definition, worked examples, counter-examples, and an explicit edge-case note. The difference is only the stakes.

Severity tiers — not all harm is equal

A flat list of categories treats a rude joke and a credible threat the same way. They are not the same, and your pipeline must not pretend they are. Layer severity tiers on top of the categories.

TierMeaningHow it's handled
CriticalCatastrophic or illegal-to-facilitate harmEscalation + senior review — never a solo annotator call
HighSerious harm to a person or groupHigher consensus count, mandatory rationale
ModeratePolicy-violating but boundedStandard labeling against the rubric
Low / benignNo real harm; possibly an over-refusalStandard labeling; over-refusals are kept (Day 52)
The highest tier is never a solo call

The most severe categories — anything touching minors, credible self-harm, mass-casualty facilitation — must route to senior review and escalation, not to whoever happened to pull the item from the queue. This protects the integrity of the label and the person looking at it. We design that routing on Day 53 and the well-being side of it on Day 54. Build the escalation path into the taxonomy from the start.

Multimodal safety: your edge applies here too

Most published safety taxonomies were written for text. Yours can't be — Grok generates images and video, and that's the terrain you know best. Harm in a generated image or clip behaves differently from harm in a sentence.

What changes when the output isn't text

This is exactly why a multimodal background is leadership-grade for a safety role: you can author categories a text-only lead would miss, and you can tell the team how to apply them to images and clips without watching every frame.

Where this fits in the field

You're not inventing this from nothing. Two papers anchor the week. Constitutional AI (Bai et al., 2022) treats a written set of principles as a guideline document at model scale — read the method section and notice that the "constitution" is a taxonomy of what to avoid, expressed as principles. And Red Teaming Language Models to Reduce Harms (Ganguli et al., 2022) is built on a categorized record of real adversarial attempts — the taxonomy is what made 38,961 attacks analyzable instead of an undifferentiated pile. A good taxonomy is what turns raw safety incidents into data you can actually learn from.

Today's move

Draft a small safety taxonomy for an image/video task you know: 4–6 categories, each with a one-line definition, plus a none/benign bucket and an other—escalate exit. Add severity tiers. Then read the Constitutional AI method section and compare your categories to its principles — where is theirs sharper than yours? That gap is your v2.

The lead move

An annotator applies a harm category. A lead authors the taxonomy that decides what "harmful" even means — drawing the mutually-exclusive boundaries, setting the severity tiers, and building the escalate exit so the team's hardest calls never land on whoever pulled the item.

Say this in an interview: "I treat a safety taxonomy as a rubric for harm: mutually-exclusive categories, severity tiers, and a deliberate escalate bucket. My multimodal background lets me write depiction and likeness categories a text-only lead would miss."

Today's Takeaways